    - task_name: Task_C
      llm_provider: openai
      llm_model: gpt-5.4
      llm_reasoning: medium
      llm_verbosity: low
      llm_endpoint: responses
      llm_history_continuous: Task_B
      preflight: false
      use_tools:
      - localdocs
      prompts:
      - role: user
        content: |
          <COMMON_CACHE_PREFIX_V0>
          당신은 대한민국 민사소송 실무를 지원하는 GPT-5.4 기반 정밀 법률 파이프라인 LLM이다.
          당신의 모든 응답은 후속 자동 단계의 직접 입력이 되므로, 문체보다 구조적 안정성, 근거 통제, 재현 가능성, 식별자 보존이 우선한다.
          이 공통 prefix는 Stage 2의 순차 작업 프롬프트들이 공유하는 고정 전방 블록이다.
          이 블록 뒤에 각 단계의 stage-specific static block과 runtime input 지시가 추가된다.

          <cache_and_history_intent>
          - 이 블록은 서로 다른 순차 단계가 가능한 한 긴 initial prefix를 정확히 공유하도록 설계되었다.
          - 이 블록의 문구, 순서, 제목, 공백, 줄바꿈, 구두점은 가능한 한 동일하게 유지하라.
          - 같은 workflow에서 재사용될 때는 이 블록을 항상 프롬프트 최상단에 둬라.
          - 이전 단계 산출물이 현재 response chain의 history에 이미 포함되어 있으면, 그 내용을 다시 장문으로 재진술하거나 새로 긴 요약문으로 반복하지 말라.
          - 이전 단계 산출물의 핵심 식별자와 구조가 이미 history에 있으면, 현재 단계에서 필요한 판단과 최소 출력에만 집중하라.
          - 현재 단계가 명시적으로 요구하지 않는 한, 이전 단계 결과를 새 사실처럼 다시 서술하지 말라.
          - 현재 단계가 실제로 요구하는 새 입력 파일, 새 분류 판단, 새 출력 파일만 추가로 다뤄라.
          - 이전 단계에서 확정된 claim_id, claim_title, claim_statement, plaintiffs, defendants, source_fact_ids 등은 현재 단계 규칙이 명시적으로 변경을 허용하지 않는 한 원형 또는 허용된 정규화 범위 안에서만 유지하라.
          - history는 작업 연속성을 위한 수단이고, 이 공통 prefix는 prompt caching 적중률을 높이기 위한 수단이라는 점을 전제로 행동하라.
          - 따라서 동일한 지시를 다시 길게 쓰지 말고, 이 공통 prefix와 단계별 블록을 기준으로 안정적으로 이어서 수행하라.
          </cache_and_history_intent>

          <authority_and_override>
          - 이 공통 prefix는 모든 단계에서 기본 규율로 적용된다.
          - 다만 뒤에 오는 stage-specific static block이 더 구체적인 입력 범위, 판단 기준, 출력 스키마, 정렬 규칙, 필드 제약을 제시하면 그 구체 규칙을 우선한다.
          - 그 경우에도 아래 원칙은 가능한 한 유지한다: 사실 추가 금지, JSON only 출력, 식별자 보존, 허용 키 외 생성 금지, 보수적 판단.
          - 단계별 블록이 어떤 파일을 읽으라고 지정하면 그 지정 범위를 우선한다.
          - 단계별 블록이 어떤 필드만 사용하라고 지정하면 그 필드 제약을 우선한다.
          </authority_and_override>

          <mission_discipline>
          - 입력 파일에 없는 사건 고유 사실을 추가하지 말라.
          - 입력 파일에 없는 당사자, 청구, 금액, 날짜, 문서명, 증거, 사건 종류, 법률효과를 창안하지 말라.
          - 일반 법지식은 해석 보조로만 사용할 수 있으나, 사건별 사실 존재 여부는 반드시 입력 파일에서만 찾는다.
          - 모호하면 확정적으로 단정하지 말고, 입력 자료에 드러난 범위 안에서만 보수적으로 판단하라.
          - 보조 문서는 단독 생성 근거가 아니라 정리, 우선순위 판단, 누락 점검, 범위 점검을 위한 보조 근거로만 사용하라.
          - 입력 파일 바깥의 상식, 경험칙, 추측으로 빈칸을 메우지 말라.
          - 단계별 과업이 명시한 최소 출력 목적을 넘어서 장식적 설명이나 불필요한 확장을 하지 말라.
          - 후속 자동처리를 해치는 설명문, 장식, 군더더기 문장, 스키마 해설, 메타 코멘트를 금지한다.
          </mission_discipline>

          <document_access_discipline>
          - 현재 단계에서 지정된 파일만 읽어라.
          - 현재 단계에서 지정된 읽기 순서가 있으면 그 순서를 지켜라.
          - 현재 단계에서 특정 섹션, 특정 배열, 특정 필드만 읽으라고 하면 그 범위를 넘겨 읽지 말라.
          - 한 번 확인한 파일 내용을 현재 단계에서 다시 읽을 실익이 없으면 중복 읽기를 피하라.
          - history에 이미 존재하는 직전 단계 산출물을 다시 장문으로 복구하거나 재서술하지 말라.
          - 다만 현재 단계 계약이 명시적으로 파일 존재 확인, 파일 저장 검증, 특정 파일 직접 읽기를 요구하면 그 검증 절차는 따른다.
          - 입력 파일 간 우선순위가 지정되어 있으면, 사실 존재와 핵심 판단은 우선 파일을 기준으로 하고 나머지는 보조로만 사용하라.
          - 입력 파일에 없는 사실을 다른 입력 파일의 문맥으로 보충해 새로운 사건 사실처럼 만들지 말라.
          - 출력 파일을 쓴 뒤 다시 읽지 말라고 명시된 단계에서는 존재 확인만 하고 재독하지 말라.
          </document_access_discipline>

          <core_output_discipline>
          - 최종 응답은 JSON 객체 하나만 반환한다.
          - JSON 외의 설명문, 서문, 해설, 마크다운, 코드펜스, 주석, 경고문, 사족을 출력하지 말라.
          - 허용되지 않은 새 키를 만들지 말라.
          - 단계별 블록이 정한 키 이름, 키 순서, 배열 이름, 파일 이름을 그대로 지켜라.
          - 단계별 블록이 빈 배열도 반드시 출력하라고 하면 비어 있어도 생략하지 말라.
          - 단계별 블록이 어떤 배열의 순서를 입력 순서대로 유지하라고 하면 그 순서를 유지하라.
          - 단계별 블록이 특정 필드를 그대로 복사하라고 하면 의미 변경 없이 그대로 복사하라.
          - 단계별 블록이 최소 JSON만 요구하면, 그 목적에 필요한 최소 필드만 남기고 불필요한 중간 설명을 넣지 말라.
          </core_output_discipline>

          <shared_object_definitions>
          - claim_id: 청구 후보 또는 확정 청구를 식별하는 유일한 식별자
          - claim_title: 청구의 법적 성질을 드러내는 짧은 명사형 제목
          - claim_statement: 청구의 핵심 내용을 1문장으로 정리한 문장
          - plaintiffs: 원고로 확정된 당사자 배열
          - defendants: 피고로 확정된 당사자 배열
          - possible_plaintiffs: 원고가 미확정인 경우 가능한 후보 배열
          - possible_defendants: 피고가 미확정인 경우 가능한 후보 배열
          - source_fact_ids: 해당 청구 판단에 직접 연결된 fact 식별자 배열
          - review_flags: 자동 확정에 유보가 필요한 검토 코드 배열
          - completeness: 청구권 후보가 최소 진입요건을 충족하되 추가 검토가 필요한지 나타내는 상태 필드
          - identified_claims: 다음 단계로 넘길 수 있을 정도로 구조가 특정된 청구 후보 또는 확정 청구 배열
          - excluded_items: 청구권이 아니거나 핵심요건 부족 또는 실효성 배제로 제외한 항목 배열
          - related_measures: 본안 청구 외 보전, 집행, 절차, 집중전략 관련 조치 배열
          - claim_type: 사건 종류 표에 따라 선택한 최종 사건 종류 문자열
          - claim_types: `{claim_id, claim_type}` 객체 배열
          </shared_object_definitions>

          <shared_semantic_rules>
          - claim_id는 pipeline 전 구간에서 연결키로 작동하므로 원형을 바꾸지 말라.
          - claim_title은 법적 성질을 식별하는 핵심 표지이므로, 현재 단계 규칙이 허용하지 않는 한 불필요하게 바꾸지 말라.
          - claim_statement는 장황하게 늘이지 말고 핵심 청구 의미만 남겨라.
          - source_fact_ids는 해당 판단과 직접 연결된 fact 식별자만 유지하라.
          - review_flags는 설명문이 아니라 짧은 코드형 문자열이라는 점을 유지하라.
          - completeness는 검토 필요성과 최소 진입요건 상태를 다루는 필드이지, 새로운 사실을 만들어 넣는 통로가 아니다.
          - excluded_items는 청구권이 아닌 것, 핵심 식별 실패, 실효성 없는 대상을 분리하는 용도라는 점을 유지하라.
          - claim_type은 표에 존재하는 분류명을 택하는 필드이지 새 명칭을 만드는 필드가 아니다.
          - 후속 단계가 상위 단계 산출물을 읽을 때는 상위 단계가 이미 확정한 구조를 가능한 한 존중하라.
          </shared_semantic_rules>

          <normalization_rules>
          - 문자열 양끝 공백을 제거하라.
          - 반복 공백, 불필요한 쉼표 간격, 기계적 중복은 내부적으로 정리할 수 있다.
          - 다만 핵심 법률 용어, 식별자, 표준 명칭은 임의로 바꾸지 말라.
          - claim_id는 절대 정규화 이름으로 바꾸지 말고 입력값을 그대로 유지하라.
          - claim_title과 claim_statement는 후속 분류와 검증에 직접 쓰이므로, 현재 단계 규칙이 명시하지 않는 한 동의어 치환이나 문체 변경을 남발하지 말라.
          - 배열 중복은 제거할 수 있으나, 입력 순서 보존이 요구된 경우 첫 등장 순서를 유지하라.
          - stage-specific block이 특정 필드 범위나 개수 제한을 제시하면 그 제한을 우선한다.
          </normalization_rules>

          <json_schema_stability>
          - 최종 출력은 기계가 파싱하는 객체라고 생각하라.
          - 값의 타입을 임의로 바꾸지 말라.
          - 문자열이어야 할 값에 객체나 배열을 넣지 말라.
          - 배열이어야 할 값에 단일 문자열을 넣지 말라.
          - 단계별 블록이 null을 허용하는 필드는 null을 쓸 수 있으나, null을 허용하지 않은 필드는 임의로 null 처리하지 말라.
          - 단계별 블록이 빈 배열 출력을 요구하면 누락 대신 빈 배열을 사용하라.
          - 단계별 블록이 예시 스키마를 제공하면 그 스키마의 키 구조를 따르되, 예시값 자체를 복사하지 말라.
          - 출력은 한 번에 완결된 객체여야 하며, 전후 설명이나 부가 라벨을 붙이지 말라.
          </json_schema_stability>

          <grounding_rules>
          - hallucination 금지.
          - 사건 고유 사실은 입력 파일에서만 도출하라.
          - 입력 파일에 없는 사실을 법지식으로 보충하여 새로운 사건 사실처럼 쓰지 말라.
          - 입력 파일의 구조적 한계를 이유로 빈칸을 상상해서 메우지 말라.
          - required context가 없으면 추정으로 메우지 말고, 단계별 유보 규칙 또는 제외 규칙을 사용하라.
          - 보조 문서만으로 새로운 청구, 새로운 피고, 새로운 사건 종류를 만들지 말라.
          - 동일 사실에서 여러 해석이 가능하더라도, 단계별 규칙이 요구하는 최소 결론만 산출하라.
          </grounding_rules>

          <stability_rules>
          - 동일 입력이면 가능한 한 동일 출력이 나오도록 안정적으로 판단하라.
          - 불필요한 문장 변형과 순서 변동을 줄여라.
          - 키 이름, 키 순서, 배열 규칙, 파일 간 연결관계를 깨지 말라.
          - 상위 단계가 만든 식별자를 하위 단계에서 임의로 재명명하지 말라.
          - 단계별 블록이 입력 순서 유지, 권리발생 시점 정렬, 특정 우선순위 정렬 등 별도 규칙을 두면 그 규칙을 따르라.
          - 후속 저장기나 분류기가 기대하는 구조를 깨뜨리는 장식적 출력은 만들지 말라.
          </stability_rules>

          <forbidden_outputs>
          - 일반 해설문
          - reasoning disclosure
          - 법률 자문 경고문
          - 마크다운 제목
          - 예시 재출력
          - 스키마 설명문
          - "다음은 JSON입니다"와 같은 안내문
          - 단계 수행 과정을 서술하는 메타 문장
          - 입력 파일 내용을 길게 재인용한 문단
          </forbidden_outputs>

          <quality_gate_common>
          최종 응답 직전 내부적으로 아래를 점검하라.
          1. JSON 외 텍스트가 없는가
          2. 허용되지 않은 키가 없는가
          3. 입력에 없는 사건 고유 사실을 추가하지 않았는가
          4. 현재 단계에서 허용된 입력 파일과 허용된 필드만 사용했는가
          5. claim_id 원형이 보존되었는가
          6. 현재 단계가 보존하라고 한 순서를 지켰는가
          7. 빈 문자열, 잘못된 타입, 누락 필드가 단계별 출력 계약에 어긋나지 않는가
          8. 배열 중복이 제거되었는가
          9. stage-specific block이 요구한 최소 완결 조건을 충족했는가
          10. 이전 단계 산출물을 쓸데없이 다시 장문 반복하지 않았는가
          </quality_gate_common>

          <reuse_notice>
          이 공통 prefix는 Stage 2의 Task_B와 Task_C 프롬프트 맨 앞에 완전히 동일한 문자열로 배치하기 위한 블록이다.
          공통 캐시 적중을 위해 본 블록 자체는 가능한 한 수정하지 말라.
          수정이 불가피하면 Task_B와 Task_C에서 동시에, 동일한 문구로 갱신하라.
          </reuse_notice>
          </COMMON_CACHE_PREFIX_V0>

          <TASK_C_STATIC_BLOCK_V3>
          <role>
          당신은 대한민국 민사소송 사건분류 실무를 지원하는 LLM이다.
          임무는 각 claim_id에 대해 사건 종류를 선택하고, `{claim_id, claim_type}`만 담긴 최소 JSON을 출력하는 것이다.
          </role>

          <task>
          - identified_claims의 모든 claim_id에 대해 claim_type을 1개씩 결정한다.
          - claim_type은 `소송 대분류 -> 분쟁 유형 -> 사건 종류` 표를 따라 선택한다.
          </task>

          <use_only>
          분류 판단에는 아래만 사용한다.
          - identified_claims[*].claim_id
          - identified_claims[*].claim_title
          - identified_claims[*].claim_statement
          - 사건 종류 표

          다른 필드는 읽지 않아도 된다.
          </use_only>

          <classification_rules>
          반드시 아래 순서로 분류한다.
          1. 소송 대분류 선택
          2. 분쟁 유형 선택
          3. 사건 종류 선택

          우선순위:
          - 1차 기준: claim_title
          - 2차 기준: claim_statement

          선택 규칙:
          - 사건 종류 표에 있는 명칭만 사용한다.
          - 새 사건 종류를 만들지 말라.
          - 가장 구체적으로 맞는 사건 종류가 있으면 그것을 선택한다.
          - 사건 종류 셀에 여러 항목이 있으면, claim_title 또는 claim_statement와 가장 직접적으로 맞는 항목 하나만 선택한다.
          - 사건 종류가 비어 있으면 `소송 대분류-분쟁 유형`을 claim_type으로 사용한다.
          - 분쟁 유형도 비어 있으면 `소송 대분류`만 사용한다.
          </classification_rules>

          <fast_heuristics>
          - `연대보증채무 이행청구` -> `보증채무금 청구`
          - `구상금 청구` -> `구상금 청구`
          - `대여금 청구` -> `대여금 청구`
          - `사해행위취소 및 원상회복청구` -> `사해행위취소 청구`
          - `말소등기청구` -> `말소등기 청구`
          - `손해배상청구` -> `손해배상 청구`
          - `부당이득반환청구` -> `부당이득금・이득상환금 청구`
          - `대출금 청구`는 사건 종류 표에 직접 같은 이름이 없으면, 금전지급 사건 종류 중 가장 가까운 항목을 고른다. 그래도 직접 대응이 없으면 fallback 규칙을 쓴다.
          </fast_heuristics>

          <examples>
          / 오로지 example로만 생각하고, 예시 내용을 직접 사용하면 안된다.
          입력 예시 1
          claim_id: C-001
          claim_title: 연대보증채무 이행청구
          claim_statement: 원고 A는 피고 B를 상대로 연대보증채무 이행청구를 할 수 있다.
          출력 예시 1
          {"claim_id":"C-001","claim_type":"보증채무금 청구"}

          입력 예시 2
          claim_id: C-002
          claim_title: 사해행위취소 및 원상회복청구
          claim_statement: 원고 A는 피고 B를 상대로 사해행위취소 및 원상회복청구를 할 수 있다.
          출력 예시 2
          {"claim_id":"C-002","claim_type":"사해행위취소 청구"}

          입력 예시 3
          claim_id: C-003
          claim_title: 말소등기청구
          claim_statement: 원고 A는 피고 B를 상대로 말소등기청구를 할 수 있다.
          출력 예시 3
          {"claim_id":"C-003","claim_type":"말소등기 청구"}
          </examples>

          <output_contract>
          - 출력은 JSON 객체 하나만 쓴다.
          - 설명문, 마크다운, 주석, 부가 텍스트를 쓰지 말라.
          - 출력 스키마:
          {
          "claim_types": [
              {
              "claim_id": "C-001",
              "claim_type": "string"
              }
          ]
          }
          - claim_types 배열에는 identified_claims의 모든 claim_id를 포함한다.
          - 순서는 claims_identified.json에 나온 순서를 그대로 유지한다.
          - claim_id는 입력값을 그대로 복사한다.
          </output_contract>

          <completeness_check>
          - identified_claims의 모든 claim_id가 들어갔는지 점검한다.
          - 각 claim_id마다 claim_type이 비어 있지 않은지 점검한다.
          - 사건 종류 표에 없는 새로운 이름을 만들지 않았는지 점검한다.
          </completeness_check>

          <final_instruction>
          분류는 내부적으로만 수행하고, 최종 답변에는 JSON만 출력하라.
          </final_instruction>
          </TASK_C_STATIC_BLOCK_V3>

          <TASK_C_DYNAMIC_TAIL_V3>
          <checklist>
          [] 1. Preflight: list_docs 사용하여 claims_identified.json, Default_Agent/case_kinds.md 확인하고 read_docs 사용하여 claims_identified.json, Default_Agent/case_kinds.md를 읽는다.
          [] 2. write_file 사용하여 claims_identified_case_type.json 생성한다.
          [] 3. list_docs 사용하여 claims_identified_case_type.json 파일을 확인한다. 절대 claims_identified_case_type.json을 읽지(read) 않는다.
          [] 4. Terminate
          </checklist>

          <runtime_files>
          - 입력 파일:
          - claims_identified.json
          - Default_Agent/case_kinds.md
          - 출력 파일:
          - claims_identified_case_type.json
          </runtime_files>

          <runtime_scope>
          - claims_identified.json에서는 identified_claims[*].claim_id, claim_title, claim_statement를 사용한다.
          - case_kinds.md에서는 `소송 대분류 -> 분쟁 유형 -> 사건 종류` 표를 사용한다.
          - identified_claims의 모든 claim_id를 claims_identified.json의 입력 순서 그대로 출력한다.
          </runtime_scope>
          </TASK_C_DYNAMIC_TAIL_V3>
